Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Speedloader Partial Reload #32396

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Rainbeon
Copy link
Contributor

About the PR

This fixes two bugs that caused partial reloads with Speedloaders to break in many many ways. Partial reloads will now function as expected. Upstreaming from RMC downstream.

Why / Balance

Fixes two bugs related to Revolvers that seem to have gone unreported on here for a long time. Currently Speedloaders will not handle partial reloads well, as they will not even attempt to look at more slots than are missing rounds, and often times these are not the ones that are hovered. This causes the Speedloader to unsuccessfully reload the missing slots, but it also still consumes ammo.

Furthermore, attempting to reload with a partially filled Speedloader would insert the rounds into the farthest possible chambers, as for some reason it was inserting them in reverse. This also fixes that.

Technical details

The i index here just tells how many slots in the Revolver the loop will look at, so I removed the Math.Min involving the amount of ammo to be loaded, as it is entirely irrelevant to how many chambers the Revolver has. There is already a Break condition present for when there isn't enough ammo that handles this correctly. Also changes the i-- behavior to i++ because by trying to reload the Revolver in reverse it put the ammo in only the farthest of slots compared to where your current index is.

Media

2024-09-23.02-37-53.mp4

Requirements

Changelog
🆑

  • fix: Fixed Revolvers not correctly reloading from Speedloaders when the Revolver is partially loaded.
  • fix: Speedloaders will now prioritize loading the active and upcoming chambers in a Revolver when the Speedloader is only partially filled, rather than the ones farthest away.

@github-actions github-actions bot added the Status: Needs Review This PR requires new reviews before it can be merged. label Sep 23, 2024
Comment on lines 132 to 135

for (var i = Math.Min(ev.Ammo.Count - 1, component.Capacity - 1); i >= 0; i--)
for (var i = 0; i < component.Capacity; i++)
{
var index = (component.CurrentIndex + i) % component.Capacity;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't that entirely duplicate lines 171-193 at this point.

Copy link
Contributor Author

@Rainbeon Rainbeon Sep 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the most part they are very similar but lines 171-193 will not run if the Speedloader Component is present, and vice versa. 171-193 only loads a single bullet and is an alternative to lines 107-168, though its method for finding where to put those bullets is correct, unlike Speedloader's current method. They attempt to do similar things, but Speedloader's version doesn't function correctly because it both looks in the incorrect direction, and it doesn't actually look through the entire cylinder, leading to it just despawning bullets without loading any of them, or putting them in bad places.

Copy link
Contributor Author

@Rainbeon Rainbeon Sep 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Furthermore what 133-158 is doing is looking through every slot from the initial position in an attempt to load multiple rounds from a container (the Speedloader), and breaking when it runs out of ammo. It grabs round types of the speedloader (which can be mixed types) and takes it out of the speedloader. It finishes after this loop is ran.

What 171-193 is doing is looking through every slot from the initial position to insert a single round from the hand and then instantly finishing inside the same loop.

They each handle a different case and don't run in parallel, not code dupe, and the loop would need to be the same regardless. These HAVE to be split and have the same For Loop definition. The only actual duping is the end sequence (outside of this loop) where it plays the sound, updates the appearances, and then dirties the comp, which is not part of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Needs Review This PR requires new reviews before it can be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants